This invention relates to a service registry and repository. In particular this invention relates to a service registry and repository based on a triplestore database for a policy editing user interface.
Service oriented architecture (SOA) is a business-driven IT architectural approach that supports integrating a business as linked, repeatable business tasks, or services. The basic building block is a service document that defines a service so that it can be managed with other services. A service document contains information about a service, including the location of the service and details about the service, and how to access the service. Service documents are used by analysts, architects, and developers during a Development Phase of the SOA life cycle to locate services to reuse and to evaluate the impact of changes to service configurations. Service documents are variously described as metadata, objects, descriptions, entities and artefacts.
A service repository stores the service document and allows access to the service document, and thereby the corresponding service. A service registry is an index of a subset of information about a service (for example the location and name of service document) enabling the corresponding service document to be located and accessed in a repository (or even the corresponding service located at the service provider). An integrated service registry and repository allows a service operation to use both the indexed service information in the registry and the detailed service information in the repository. An example of an integrated service registry and repository is IBM® WebSphere® Registry and Repository (WSRR).
Such an integrated service registry and repository has advantages of greater business agility and resilience through reuse than separate systems. Further advantages of looser coupling, greater flexibility, better interoperability, and better governance arise from the integration. These advantages are addressed by separating service descriptions from their implementations, and using the service descriptions across the life cycle of the service. Standards-based service metadata artefacts, such as Web Service Definition Language (WSDL), extensible mark-up language (XML) schema, policy or Service Component Architecture (SCA) documents, capture the technical details of what a service can do, how it can be invoked, or what it expects other services to do. Semantic annotations and other metadata may be associated with these artefacts to offer insight to potential users of the service on how and when it may be used, and what purposes it serves.
WS-Policy is a World Wide Web Consortium (W3C) standard that specifies policy documents for web services. A WS-Policy document that conforms to the W3C standard declares policies (top level elements), assertions (rules that must be adhered to) inside those policies, and properties for these assertions (for example an assertion may be declared to be optional within a policy). Standard types of policy document (also covered by the W3C) called domain policy definitions include: security (WS-Security); reliable messaging (WS-RM); addressing (WS-A). Each of these domain policy definitions describes the required structure for the policy XML files in order to conform to the standard.
An example of a domain policy definition is an XML document defining what type of authentication tokens must be supplied when accessing a web service. WS-Policy-Attach domain policy definition specifies a standard approach by which policy attachments may be defined. In the context of a service registry environment, this becomes particularly relevant as the service registry exists as a point-of-record for web services definitions and thus it is desirable to make these associations between policies and their subjects within the registry.
Standard tools create WS-Policy and WS-Policy-Attach policy documents, and even a text editor may be used for this purpose if the user is well versed in the various WS-Policy specifications. However, the structure of both the policy and the policy attachment specifications requires a high level of knowledge from the users in order to correctly specify everything. Most often errors are made by a user when creating policy documents.